Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-084.TXT

Text File | 1992-06-30 | 44.5 KB | 1,121 lines

C.S.M.P. Digest             Sun, 17 May 92       Volume 1 : Issue 84

Today's Topics:

    Error on High Density Floppies
    Localization (was: ResEdit Easter Eggs)
    Patching traps at INIT time under sys. 7
    Two basic questions from an advanced programmer
    Large pointer blocks
    I need your opinion
    Fancy Your Tickle...
    QUESTION-Drawing Pict/Hide MenuBar??
    GKS for Mac?  C bindings?
    PATCHING THE FINDER (?)
    d e v e l o p
    Using "OpenStdCompression" with MPW QuickTime headers in THINK C


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Paul McIlroy)
Subject: Error on High Density Floppies
Date: 13 Apr 92 22:41:38 GMT
Organization: British Telecom

We have a number of high density floppy disks (MFM format) which were
written over a year ago using a MacIIci.  They were kept in a drawer
sharing a box with some 800k floppies.  The 800k floppies are still
fine, but the high density disks are now all unreadable.  Attempts to
mount them returns ERROR -400 gcrOnMFMErr (gcr format on high density
media error).  I do not believe that there is a hardware error on the
IIci, since newly formatted MFM disks which it writes can be read by
other Macs without problem.  We have been unable to fix these disks
with either MacTools Rescue (version 1.1) or Norton Utilities.  Has
anybody else had similar problems with high density floppies ? And
does anybody know of any way to rescue disks from gcrOnMFMErr ?

Paul McIlroy ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Steve Christensen)
Date: 16 Apr 92 02:03:27 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Paul McIlroy) writes:

>We have a number of high density floppy disks (MFM format) which were
>written over a year ago using a MacIIci.  They were kept in a drawer
>sharing a box with some 800k floppies.  The 800k floppies are still
>fine, but the high density disks are now all unreadable.  Attempts to
>mount them returns ERROR -400 gcrOnMFMErr (gcr format on high density
>media error).  I do not believe that there is a hardware error on the
>IIci, since newly formatted MFM disks which it writes can be read by
>other Macs without problem.  We have been unable to fix these disks
>with either MacTools Rescue (version 1.1) or Norton Utilities.  Has
>anybody else had similar problems with high density floppies ? And
>does anybody know of any way to rescue disks from gcrOnMFMErr ?

gcrOnMFMErr means that the high density disk _looks_ like it was initialized
using one of the 800K disk drives (i.e., pre-Mac IIx).  An easy way to see
if this is really the case is to put some tape over the extra hole in the
disk shell, stick it into the drive and see if it shows up on the desktop.
If it does, perhaps someone has been playing around with the disks in your
drawers...

If this is indeed what happened, you may find you need a bulk eraser (or a
strong magnet) to properly erase the HD disks before you use them again.
The old 800K drives generate a stronger field on the read/write head, so the
data is imbedded deeper in the media than on the SuperDrives.  Your luck may
vary on this.

If the disk doesn't show up on the desktop and Norton can't deal with it,
then I'm not sure what the problem might be.

steve

- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.

---------------------------

From: [e-mail] (Dave Elliott)
Subject: Localization (was: ResEdit Easter Eggs)
Organization: Washington University, St. Louis Mo.
Date: Thu, 2 Apr 1992 07:06:30 GMT

If you have the "20,000 Leagues Under the CD" CD-ROM from the Spring
Develop magazine, and know a little Chinese, look at ChineseTalk II
in International Software. There is a localization system here which
is really slick. You first install a normal System 7.0x. Then install
the extension ScriptT which implements ChineseTalk, and the folders
(especially the ScriptT Folder for fonts, and the Localization Folder)
that go in your System Folder. Now, for each of your utilities [and if
you can read Chinese] the Localization Editor (with the clown-face icon)
will, for *each* of your applications, such as MacWrite II etc.,
install the Chinese resources into the *Localization Folder* where the
system software can find them... and you have the option, by using
Option-Z at startup, of putting them to sleep or (Option-K) killing them.
That gets you back to a US system with no pain.
If the experts in Taiwan and at Apple who produced this want to work on
other country localizations, really global Macs will result!

    If you are seriously concerned with localization--
even if you don't read Chinese, ask a friend who does to look at this
with you, especially if you have a spare partition or external hard disk
to install on. I doubt a floppy would suffice.


                                David L. Elliott
                Dept. of Systems Science and Mathematics
                                Washington University, St. Louis, MO 63130
                [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Arno Gourdol)
Date: 4 Apr 92 17:06:03 GMT
Organization: IMAG Institute, University of Grenoble, France

[How you can make a chinese system by starting with a US system
and adding 'localization' resources in the system]
>If the experts in Taiwan and at Apple who produced this want to work on
>other country localizations, really global Macs will result!

It is rumored (or, if it wasn't now it is) that System 7.1 due in
September will contain this 'feature' for every languages.
That is, instead of localizing say, a french version of the system,
you will use a 'standard' System 7 with added 'french' resources.
This way, you should be able to use multi-lingual systems,
for example french, english, japanese and arabic. Isn't life fun :-)

Arno.

- --
Arno Gourdol.  <[e-mail]>
Minds, like parachutes, only function when open.

+++++++++++++++++++++++++++

From: [e-mail] (John H. Jenkins)
Date: 6 Apr 92 15:30:17 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Arno Gourdol) writes:
>
> [How you can make a chinese system by starting with a US system
> and adding 'localization' resources in the system]
> >If the experts in Taiwan and at Apple who produced this want to work on
> >other country localizations, really global Macs will result!
>
> It is rumored (or, if it wasn't now it is) that System 7.1 due in
> September will contain this 'feature' for every languages.
> That is, instead of localizing say, a french version of the system,
> you will use a 'standard' System 7 with added 'french' resources.
> This way, you should be able to use multi-lingual systems,
> for example french, english, japanese and arabic. Isn't life fun :-)
>
> Arno.


Actually, System 7.0 already has this capacity.  By just dropping a bunch
of stuff into my system folder, I added the ability to handle Hebrew in
addition to English, for example -- at least in programs that use the
Script Manager correctly :-(

System 7.1 will make it possible to do this for the two-byte systems
(both Chineses, Japanese, and Korean) in addition to the one-byte ones.

John H. Jenkins
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (John H. Jenkins)
Date: 6 Apr 92 15:30:17 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Arno Gourdol) writes:
>
> [How you can make a chinese system by starting with a US system
> and adding 'localization' resources in the system]
> >If the experts in Taiwan and at Apple who produced this want to work on
> >other country localizations, really global Macs will result!
>
> It is rumored (or, if it wasn't now it is) that System 7.1 due in
> September will contain this 'feature' for every languages.
> That is, instead of localizing say, a french version of the system,
> you will use a 'standard' System 7 with added 'french' resources.
> This way, you should be able to use multi-lingual systems,
> for example french, english, japanese and arabic. Isn't life fun :-)
>
> Arno.


Actually, System 7.0 already has this capacity.  By just dropping a bunch
of stuff into my system folder, I added the ability to handle Hebrew in
addition to English, for example -- at least in programs that use the
Script Manager correctly :-(

System 7.1 will make it possible to do this for the two-byte systems
(both Chineses, Japanese, and Korean) in addition to the one-byte ones.

John H. Jenkins
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Gavriel State)
Date: 15 Apr 92 20:05:58 GMT
Organization: University of Waterloo

In article <[e-mail]> [e-mail] (John H. Jenkins) writes:
>Actually, System 7.0 already has this capacity.  By just dropping a bunch
>of stuff into my system folder, I added the ability to handle Hebrew in
>addition to English, for example -- at least in programs that use the
>Script Manager correctly :-(

Hmmm.  Looking at IM-VI's script manager chapter, one of the screen shots
clearly shows the script menu pulled down with multiple languages (Hebrew,
Japaneese, etc.) available.  Thing is, the last developer CD I saw didn't
have the 7.0-compatable Hebrew (or Arabic or any non-latin language)
resources.  I tried for almost a day to hack the 6.0.8 Hebrew resources
into a usable form but to no avail.  Is this stuff ready on the latest
Developer CD?  The one I had was the december '91 issue.....


- --
Gavriel State | 2A Systems Design Engineering/Economics | University of Waterloo
[e-mail] (School)  |  "What in God's name is going on?"
[e-mail] (> Apr 17) |   "FOUL!  No rhetoric!  Two-one!"
[phone] (Waterloo)              | Rosencrantz and Guildenstern are Dead

---------------------------

From: [e-mail] ([e-mail])
Subject: Patching traps at INIT time under sys. 7
Date: 4 Apr 92 22:35:27 GMT
Organization: Johns Hopkins University

I am trying to patch the trap _initwindows in an INIT.  It seems to work
fine under system 6.0.x, but I have determined that when the finder loads
under system 7 it seems to do a wholesale replacement of many trap addresses
without linking to the existing patch code (i.e. those put in before the
finder loaded)!  I haven't found anything in I.M VI that warns me about this
either.  It seems like I must be missing something very fundamental here
since all the other INITs that I have seem to be able to use _settrapaddress
to successfully patch traps made after the finder loads.

Does anyone know what I'm doing wrong??  Please respond via E-mail
to [e-mail]

Thanks

Harry Eaton



- --

+++++++++++++++++++++++++++

From: [e-mail] (Dean Yu)
Date: 10 Apr 92 17:17:02 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] ([e-mail]) writes:
>
> I am trying to patch the trap _initwindows in an INIT.  It seems to work
> fine under system 6.0.x, but I have determined that when the finder loads
> under system 7 it seems to do a wholesale replacement of many trap addresses
> without linking to the existing patch code (i.e. those put in before the
> finder loaded)!  I haven't found anything in I.M VI that warns me about this
> either.  It seems like I must be missing something very fundamental here
> since all the other INITs that I have seem to be able to use _settrapaddress
> to successfully patch traps made after the finder loads.
>
> Does anyone know what I'm doing wrong??  Please respond via E-mail
> to [e-mail]
>

  You're not doing anything wrong.  The Process Manager completely replaces
_InitWindows with its own version when it starts up.  And you're right.  It
doesn't call through to the old one.

  -- Dean Yu
     Blue Meanie, Negative Ethnic Role Model, Window Cleaner,
      Skanky Hack Consultant, etc.
     Apple Computer, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Mon, 13 Apr 1992 04:06:34 GMT

In article <[e-mail]>, [e-mail] (Dean Yu) writes:
>
> In article <[e-mail]>, [e-mail] ([e-mail]) writes:
> >
> > I am trying to patch the trap _initwindows in an INIT.  It seems to work
> > fine under system 6.0.x, but I have determined that when the finder loads
> > under system 7 it seems to do a wholesale replacement of many trap addresses
> > without linking to the existing patch code (i.e. those put in before the
> > finder loaded)!  I haven't found anything in I.M VI that warns me about this
> > either.  It seems like I must be missing something very fundamental here
> > since all the other INITs that I have seem to be able to use _settrapaddress
> > to successfully patch traps made after the finder loads.
>
>   You're not doing anything wrong.  The Process Manager completely replaces
> _InitWindows with its own version when it starts up.  And you're right.  It
> doesn't call through to the old one.

Yeah, it does the same with the _Launch trap.  My hackaround was to patch
_SetTrapAddress and watch while it patches _Launch and then repatch _Launch.
Very very very very very evil and yukky and horrible and full of compatibility
probelms (but it worked and it wasn't in a shipping product).

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia


+++++++++++++++++++++++++++

From: [e-mail] (Ken McLeod)
Date: 15 Apr 92 02:04:02 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Dean Yu) writes:
>
> In article <[e-mail]>, [e-mail] ([e-mail]) writes:
> >
> > I am trying to patch the trap _initwindows in an INIT.  It seems to work
> > fine under system 6.0.x, but I have determined that when the finder loads
> > under system 7 it seems to do a wholesale replacement of many trap addresses
> > without linking to the existing patch code (i.e. those put in before the
> > finder loaded)!
>
>   You're not doing anything wrong.  The Process Manager completely replaces
> _InitWindows with its own version when it starts up.  And you're right.  It
> doesn't call through to the old one.

A solution might be to patch SetTrapAddress, watch for attempts to change
the address of the _InitWindows trap, then stuff that new address somewhere
and JMP to it yourself at the end of your _InitWindows [head] patch.

- -ken

- --
Ken McLeod
Apple Computer, Inc.
AppleLink: THE.CLOUD  Internet: [e-mail]

---------------------------

From: [e-mail] (Scott Bronson)
Subject: Two basic questions from an advanced programmer
Date: 6 Apr 92 01:56:58 GMT

Here are two things that I've noticed that everyone implements differently.
Is there any standard on when to use them and when not to?

(1) Some sample code that I've downloaded expressly checks DiskInserted
events, then calls DIBadMount depending on the event.  Other code that
I've seen totally ignores DiskInserted events.  If my application does
nothing funny with disks other than opening, reading, and writing files,
should I check for DiskInserted during my event loop, or is that redundant?

(2) I've implemented my own button.  However, it could take all of the
processor's time for a long time if the user presses and holds the
mouse button down on this button.  Some code that I've seen just eats
up time in a tight loop with nothing in it until the mouse is released,
some call SystemTask() and I'm sure some do something totally different.
I don't want a background modem transfer to grind to a halt just because
somebody pressed and held down the button in my app.

What should I do?

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 10 Apr 92 20:14:27 GMT
Organization: Apple Computer, Inc.

In article <scott.702525418@mcl>, [e-mail] (Scott Bronson) writes:
>
> Here are two things that I've noticed that everyone implements differently.
> Is there any standard on when to use them and when not to?
>
> (1) Some sample code that I've downloaded expressly checks DiskInserted
> events, then calls DIBadMount depending on the event.  Other code that
> I've seen totally ignores DiskInserted events.  If my application does
> nothing funny with disks other than opening, reading, and writing files,
> should I check for DiskInserted during my event loop, or is that redundant?
>
> (2) I've implemented my own button.  However, it could take all of the
> processor's time for a long time if the user presses and holds the
> mouse button down on this button.  Some code that I've seen just eats
> up time in a tight loop with nothing in it until the mouse is released,
> some call SystemTask() and I'm sure some do something totally different.
> I don't want a background modem transfer to grind to a halt just because
> somebody pressed and held down the button in my app.
>
> What should I do?
>
>     - Scott

All applications should be checking for diskInserted events.

While the mouse is held down, all non-interrupt tasks stop to track
the mouse.  For example, while you drag a window or pop down a menu
no other processing except for interrupts takes place.  It's a fundamental
aspect of the Mac OS.  Some programmers feel they should try to give
time to other tasks while they track the mouse.  Calling SystemTask
will give some time to drivers that "needsTime".  For example, a Desk
Accessory such as the clock will update the seconds during calls to
SystemTask.  Serial Drivers on the other hand are interrupt driven,
and are not using SystemTask for time.  The application will poll to
get data but calling SystemTask will not give time to a background
application.  So, a modem application will halt the input of serial data
because it's using hand shaking.  You'd have to call WaitNextEvent
to give the background applications time, but this is starting to get
a bit complicated.

You're button isn't any different from the System's buttons (or WDEF,
MDEF, MBDF, etc. for that matter).  The entire OS stops to track the
mouse while in the down position.  I wouldn't worry about it.  Most
user don't hold the mouse down for extended periods of time.  And if
they do, they're not expecting something to be happening in the
background.


- -----------------------------------------------------------------------
Jim Reekes, E.O.             |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 13 Apr 92 03:36:35 GMT
Organization: Dartmouth College, Hanover, NH

Here're some basic answers from a begining programer.

> (1) Some sample code that I've downloaded expressly checks DiskInserted
> events, then calls DIBadMount depending on the event.  Other code that
> I've seen totally ignores DiskInserted events.  If my application does
> nothing funny with disks other than opening, reading, and writing files,
> should I check for DiskInserted during my event loop, or is that redundant?

I'm pretty sure that the Standard File Package handles all of this, but
I don't have Inside Mac vol. IV, so I'm only sure it works for the 128
and 512. The Standard File Package handles all drive access and returnd
all the pertinent info to your app.
As for (2):

>(2) I've implemented my own button.  However, it could take all of the
>processor's time for a long time if the user presses and holds the
>mouse button down on this button.  Some code that I've seen just eats
>up time in a tight loop with nothing in it until the mouse is released,
>some call SystemTask() and I'm sure some do something totally different.
>I don't want a background modem transfer to grind to a halt just because
>somebody pressed and held down the button in my app.

I'm pretty sure that if you "just eat up time in a tight loop" there
won't be any background tasks, but I'm not sure. To be safe, I'd call
SystemTask.

Hope this helps,
Jeremiah Blatz
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 14 Apr 92 18:40:12 GMT

I got a few good answers for this post, so I'll summarize here:
(I omitted names because no one expressly gave me permission to use
 their quote here -- thanks to all of them, though).

Yes, your app does need to check for and respond to DiskInserted
events, calling DIBadMount when needed.  I have some sample code
that you can simply paste into your event loop to add this capability
for all you who haven't yet.  It's actually really easy -- only about
four lines or so.  You can also find sample code (and a lot of it!)
in the book _Programming for System 7_ (part of the Macintosh Inside
Out series published by Addison-Weseley), a book that I read and
use a lot (and have no afilliation with).

And, as I feared, there are many ways to go about tracking the mouse.
The easiest way is simply to call SystemTask inside your loop, but
that's not the best way.  The way that makes the most sense to me
is to simply keep running through your main event loop, tracking
the mouseDown across calls to WNE.  I haven't tried this yet, and it
sounds like it just adds more to an already overloaded main event
loop.  It also sounds like it could make tracking the mouse button
sluggish if there's a lot going on in the background and perhaps from
a UI standpoint that's not good.  I'd rather have my computer appear
sluggish than abort a transfer in the background for lack of processor
time, though!

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Tue, 14 Apr 1992 21:29:53 GMT

In article <scott.703276812@mcl> [e-mail] (Scott Bronson) writes:
>
>The way that makes the most sense to me
>is to simply keep running through your main event loop, tracking
>the mouseDown across calls to WNE.
>I'd rather have my computer appear
>sluggish than abort a transfer in the background for lack of processor
>time, though!

I don't know of any programs that go to this extreme.  It makes sense if
the user will have to drag something for a long time.  But the Finder
doesn't even do this for file-dragging.

If you're really concerned, I hear there's an INIT that calls SystemTask
or EventAvail or something during menu selection.  I'd have reservations
about its compatibility, though.

And it's been my experience that file transfers can survive a lot.
White Knight and ZTerm both handle ZModem quite well for ten or fifteen
seconds without events (at 2400 baud).
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Ceci n'est pas une .signature.

---------------------------

From: [e-mail] (Michael F. Kamprath)
Subject: Large pointer blocks
Date: 7 Apr 92 01:50:35 GMT
Organization: The University of Michigan, Ann Arbor

I've been writing several computational programs lately on the mac
(in THINK C 4.0.5) and I've finally figured out (with some help) a
stable way to handle large arrays using pointers.  But now that
my programs are stable, I would like to increase the array size
but I can't allocate pointers for memory blocks larger than about
30K of RAM.  I think I read some where that this is a natural limitation
in the Mac.  My question is, if my program heap is, for example, 2 Megs
of RAM, my coding only taking up the first 50K of RAM, why
can't I (or how can I) use the rest of the 1.95 Megs of RAM for arrays
to be manipulated by the code?  If I am limited to 32K of usable array
(or pointer) accesable memory, is there a clever way to circumvent this,
short of saving blocks of memory to a hard drive?

I am using a IIci to do my programing on.  Does the new Quadra have this
same memory limitation?  If so, how can Apple seriousely try to put it off as
a "powerful", "number crunching", "Atila the Hun" type of computer?

I realize a Mac is slow when compared to DEC stations and the such, so it
may not be my best choice for heavy number crunching.  But it is accesible
and overnight runs are not impratical for me. If anybody could help me solve
this memory problem, I'd really appreciate it.

Michael Kamprath
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Tue, 7 Apr 1992 20:57:44 GMT

.edu> [e-mail] (Michael F. Kamprath) writes:

   my programs are stable, I would like to increase the array size
   but I can't allocate pointers for memory blocks larger than about
   30K of RAM.  I think I read some where that this is a natural limitation

Only for statically allocated arrays. However, Think C malloc
in version 4 takes an int for argument; you lose for > 32k.
Use calloc instead ! It takes two 16-bit ints, which multiply
correctly. You're probably already including stdlib.h, but
check for that too :-)

NewPtr and NewHandle (built-in memory allocators in the mac)
take long ints as parameters; they can allocate as much memory
as you have RAM (or VM)

   I am using a IIci to do my programing on.  Does the new Quadra have this
   same memory limitation?  If so, how can Apple seriousely try to put it
   off as a "powerful", "number crunching", "Atila the Hun" type of computer?

As you probably realize, it's a design limitation in the Think C 4
compiler, not in the mac. Even the Mac 128 could allocate > 32k
memory if you had that much free...

If you're going to program the mac seriously, you got to get the
Inside Mac volumes (all six of them except volume III)

   I realize a Mac is slow when compared to DEC stations and the such, so it
   may not be my best choice for heavy number crunching.  But it is accesible
   and overnight runs are not impratical for me. If anybody could help me solve

Hey, a Quadra runs circles around a DecStation 3000s (?) and is
quite comparable to various Sparcs. And even a PowerBook is much
snappier in user response than anything running X windows...

Unless you run MacX on your PB using Remote Access of course :-)

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

+++++++++++++++++++++++++++

From: [e-mail] (Donald T. Major)
Date: 8 Apr 92 22:09:29 GMT
Organization: SAS Institute Inc.

How are you allocating the memory?  NewPtr has no such limitation,
unless your heap is incredibly fragmented and uncompactible (for the
amount of RAM you had in your application :-)).  This seems unlikely,
so perhaps you're using malloc() or calloc() (or whichever such
functions are available in the THINK C ANSI library)?

- --
Donald Major       SAS Institute Inc.  "Cicely, let's fling something!"
[e-mail] SAS Campus Drive                 - Northern Exposure
[phone]     Cary, NC 27513-2414

+++++++++++++++++++++++++++

From: [e-mail] (Michael Kamprath)
Date: 12 Apr 92 04:30:11 GMT
Organization: The University of Michigan, Ann Arbor

In article <[e-mail]>, [e-mail] (Donald T. Major) writes:
>
> How are you allocating the memory?  NewPtr has no such limitation,
> unless your heap is incredibly fragmented and uncompactible (for the
> amount of RAM you had in your application :-)).  This seems unlikely,
> so perhaps you're using malloc() or calloc() (or whichever such
> functions are available in the THINK C ANSI library)?
>
> --
> Donald Major       SAS Institute Inc.  "Cicely, let's fling something!"
> [e-mail] SAS Campus Drive                 - Northern Exposure
> [phone]     Cary, NC 27513-2414
>
>

OK, I found out what was happening.  I was getting pointers limited to 32K
of RAM.  I confused this problem with the limitation of 32K to stack
variables.  What the problem ended up being was that I was using variable
of type (Size) to pass how large I need a block.  (Size) is actually
 a (short int), and (short int) can only go up to 32K.  Once I changed
my variables to (long int), my problem disappear, and my faith in the
Mac as a computational machine was restored.

Michael Kamprath
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Michael Kahl)
Date: 16 Apr 92 02:23:30 GMT
Organization: Enginuity Inc.

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>[...] Think C malloc
>in version 4 takes an int for argument; you lose for > 32k.
>Use calloc instead ! It takes two 16-bit ints, which multiply
>correctly.

Not so.  "malloc" takes a "size_t", which is an unsigned long.  "calloc" takes
two "size_t"s.  Thus both routines work with 32-bit ints and allow allocation
of objects exceeding 32K.

Even in ThC 4, the libraries were ANSI Standard, even if the compiler itself
didn't become so until version 5.
- --
Michael Kahl, Software Architect, Enginuity Inc.
[e-mail]  -or-  [e-mail]
Disclaimer:  Whoa!  Did I say THAT??!

---------------------------

From: [e-mail] (GILPIN, W.W.)
Subject: I need your opinion
Date: 7 Apr 92 10:03:00 GMT
Organization: Texas A&M University, Academic Computing Services


I know this probably isn't the best place for this, but so what.

I need answers to the following question:

If you were to buy a computer today, and had to choose between an IBM/PC
or clone and an Apple Macintosh, which would you choose and why?

Mac and IBM are the only two platforms I'm evaluating in this report, so
please limit your answers to these two machines.
E-mail only please...I don't want to start a flame war, I want useful opinions.
Thanks for any responses.

Wes Gilpin
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail]
Date: 14 Apr 92 20:00:47 -500
Organization: Cleveland State University

In article <[e-mail]>, [e-mail] (GILPIN, W.W.) writes:
>
> I know this probably isn't the best place for this, but so what.
>
> I need answers to the following question:
>
> If you were to buy a computer today, and had to choose between an IBM/PC
> or clone and an Apple Macintosh, which would you choose and why?
>
> Mac and IBM are the only two platforms I'm evaluating in this report, so
> please limit your answers to these two machines.
> E-mail only please...I don't want to start a flame war, I want useful opinions.
> Thanks for any responses.
>
> Wes Gilpin
> [e-mail]

Dear Wes,

  I would choose a mac because of the user interface (operating system).  It is
easier to use for most people.  Also in IMB land there are many program
interfaces (LIKE lotus versus word perfect), and you need to read the entire
manual to get started.  Not in Mac with te user interface.


---------------------------

From: [e-mail] (Tim Endres)
Subject: Fancy Your Tickle...
Date: 9 Apr 92 04:07:05 GMT
Organization: ICE Engineering, Inc.


Tickle 3.1v4 is now available for general consumption.
This new release fixes bugs, adds a couple things, and also
splits the package into several pieces.

Where:

ftp.msen.com
pub/vendor/ice/tickle/



tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Brent)
Date: 9 Apr 92 18:14:20 GMT
Organization: Texas A&M Univ., Inc.

[e-mail] (Tim Endres) writes:
|
|Tickle 3.1v4 is now available for general consumption.
| time e.

I had the version that was available in March and I have a question.
Is there some variables I need to set with it so that it can find
the scripts.  For example, when I give it some commands that are
documented in the tickle manual, it tells me that that command is
not found.

Sorry this is general, but I'm not at my macintosh to check the settings.

I had the PATH variable set to the directories that contain scripts,
but this didn't seem to work (the path was set in the tclrc file, I believe).

Any hints are appreciated  and thanks for your work, Tim.

- -Brent

- --
- ------------------------------------------------------------------------------
Brent P. Burton, N5VMG                                    Computer Sci/Physics
[e-mail]                                   Texas A&M University
- ------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 10 Apr 92 13:40:35 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.apps), [e-mail] (Brent) writes:
> |
> |Tickle 3.1v4 is now available for general consumption.
> | time e.
>
> I had the version that was available in March and I have a question.
> Is there some variables I need to set with it so that it can find
> the scripts.  For example, when I give it some commands that are
> documented in the tickle manual, it tells me that that command is
> not found.
>
> Sorry this is general, but I'm not at my macintosh to check the settings.
>
> I had the PATH variable set to the directories that contain scripts,
> but this didn't seem to work (the path was set in the tclrc file, I believe).
>
> Any hints are appreciated  and thanks for your work, Tim.

you can get a list of command with:

    foreach name [info commands] {puts stdout $name}

Anything not in this list is not available as a command. These commands
are built into tickle and do not need access to any file to be used.

As for commands that are defined in scripts, they will not be available
until you "source script.tcl" them...

tim.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

---------------------------

From: [e-mail] (Bret Alvin Barker)
Subject: QUESTION-Drawing Pict/Hide MenuBar??
Date: 12 Apr 92 02:40:08 GMT
Organization: Worcester Polytechnic Institute


       This is probably a very easy question to answer, but how do I read a
PICT resource and display the PICT in the current cgrafport.  Also, how do I
hide the MenuBar?  If anyone could E-mail me a code segment in either Think-C
or Think-Pascal, I would greatly appreciate it.

            --bret a. barker
              [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 13 Apr 92 14:08:43 GMT
Organization: The World Public Access UNIX, Brookline, MA

> This is probably a very easy question to answer, but how do I read a
> PICT resource and display the PICT in the current cgrafport.

Look into the DrawPicture(thePicture, destRect); routine.
- --
<--------------------------------------------------->
 joe zobkiw                     [e-mail]
 mac.synthesis.MIDI.development.C.asm.communications
>---------------------------------------------------<

---------------------------

From: [e-mail] (Greg Trimper)
Subject: GKS for Mac?  C bindings?
Date: 11 Apr 92 22:38:21 GMT
Organization: Enterprise Data Systems Incorporated, Appleton WI

does anyone know if GKS is available for the Mac?  If so, where nad
how can I get it?  And does it hopefully have C bindings?



Greg Trimper   [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 12 Apr 92 05:22:27 GMT
Organization: University of Illinois at Urbana

[e-mail] (Greg Trimper) writes:

>does anyone know if GKS is available for the Mac?  If so, where nad
>how can I get it?  And does it hopefully have C bindings?

I doubt it. But there's a successor called SRGP based on both X and
QuickDraw, and available for both machines.  SRGP is described in Foley
and Van Dam; there's some srgp (and sphigs) stuff on wuarchive as
graphics/graphics/srgp.tar.Z (and sphigs.tar.Z).
- --
Mark Lanett, Software Tools Group, NCSA           [e-mail] or  NCSA.STG
"People wander in and out of virtual rooms in virtual settings with virtual
characters and virtual money and virtual armor and virtual weapons, which is
virtually a good way to spend time, but not quite." -- Usenet Oracle
- --
Mark Lanett, Software Tools Group, NCSA           [e-mail] or  NCSA.STG
"People wander in and out of virtual rooms in virtual settings with virtual
characters and virtual money and virtual armor and virtual weapons, which is
virtually a good way to spend time, but not quite." -- Usenet Oracle

---------------------------

From: [e-mail] (Scott Laing)
Subject: PATCHING THE FINDER (?)
Date: 12 Apr 92 07:57:53 GMT
Organization: Project EOS - North Carolina State University

Hello, I'm trying to modify an INIT I wrote sometime ago so it will patch
the Finder on start-up, rather than modify the shutdown queue.  All it has
to do is change the routine when "Shutdown" is chosen so that a dialog (of
my own) is shown before ShutDwnPower is called.

Something that does this is Grouch.  It places a menu item to display an
about box in the Special menu.

Does anyone have any example code to do this?  Know where I can find some?

Thanks,
Scott
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 13 Apr 92 17:59:43 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Scott Laing)
writes:
>
> Hello, I'm trying to modify an INIT I wrote sometime ago so it will patch
> the Finder on start-up, rather than modify the shutdown queue.  All it has
> to do is change the routine when "Shutdown" is chosen so that a dialog (of
> my own) is shown before ShutDwnPower is called.
>
> Something that does this is Grouch.  It places a menu item to display an
> about box in the Special menu.
>
> Does anyone have any example code to do this?  Know where I can find some?

I don't have any sample code for you, but I do know that the Grouch patches
MenuSelect to do its stuff. To see how they did it, you can do the same thing I
did: I disassembled the Grouch INIT.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


---------------------------

From: [e-mail] (Chuck Shotton)
Subject: d e v e l o p
Date: 14 Apr 1992 15:13:22 GMT
Organization: UTHSCH Academic Computing

Has Apple stopped distributing "hardcopy" versions of d e v e l o p to
developers? I can't remember the last time I got one. It's a real pain to
try and read those things on-line from the CD-ROM....

Chuck

+++++++++++++++++++++++++++

From: [e-mail] (Greg Trimper)
Date: 15 Apr 92 00:03:08 GMT
Organization: Enterprise Data Systems Incorporated, Appleton WI


Is d e v e l o p Issue 10 out?  I ask, as I sent in a renewal slip,
but my VISA was not charged as of last month, I it is spring,
and i don't have an Issue 10...


Greg Trimper   [e-mail]

---------------------------

From: [e-mail] (Paul Potts)
Subject: Using "OpenStdCompression" with MPW QuickTime headers in THINK C
Date: 14 Apr 92 18:13:00 GMT
Organization: Instructional Technology Laboratory, University of Michigan

I got an answer about using "OpenStdCompression" in THINK C. The solution
is to put the call, and the prototype in the header file, into all capitals:
OPENSTDCOMPRESSION.

The reasons seems to be that the MPW linker isn't case-sensitive, while
the THINK C
linker is. Therefore the .o library has the glue call listed as
OPENSTDCOMPRESSION; under MPW it works to call it by OpenStdCompression, but
not under THINK.

The OConv utility seems to create a project that can't be opened by THINK C.
Does anyone know why this is? I get a "ZREF error" - "Please remove objects"
when I try to open the resulting project file.
- --
Paul Potts - [e-mail]
Un damne' descendant sans lampe,/ Au bord d'un gouffre dont l'odeur
Trahit l'humide profondeur,/ D'e'ternels escaliers sans rampe...
   -Baudelaire on DOS/Windows programming

+++++++++++++++++++++++++++

From: [e-mail] (Kenneth Knight)
Date: 15 Apr 92 17:13:40 GMT
Organization: Instructional Technology Laboratory, University of Michigan

In article <[e-mail]> [e-mail] (Paul Potts) writes:
>I got an answer about using "OpenStdCompression" in THINK C. The solution
>is to put the call, and the prototype in the header file, into all capitals:
>OPENSTDCOMPRESSION.
>
>The reasons seems to be that the MPW linker isn't case-sensitive, while
>the THINK C
>linker is. Therefore the .o library has the glue call listed as
>OPENSTDCOMPRESSION; under MPW it works to call it by OpenStdCompression, but
>not under THINK.
>
>The OConv utility seems to create a project that can't be opened by THINK C.
>Does anyone know why this is? I get a "ZREF error" - "Please remove objects"
>when I try to open the resulting project file.

One other thing that is worth mentioning. It is very important that you
include the resources for the StdCompression module somewhere in the
application's resource path. They don't exist in a vacuum and the docs on
the module don't really mention them. A complete set can be found in the
.rsrc file that is in the Compression Dialog folder on the QuickTime CD.
The resource all have IDs around 32000 and include 2 DLOGs (and their DITLs),
THING, sodi, STR#, and some others that I can't recall right now.

If you do not include ALL the resources when you attempt to do the:
   component_instance (some variable) = OpenStdCompression();
your variable will always return nil. I have no idea if checking one of the
error functions would give any more detailed data, but I have my doubts.

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 16 Apr 92 14:14:50 GMT
Organization: Symantec Corp.

In article <[e-mail]> [e-mail] (Paul Potts) writes:

   I got an answer about using "OpenStdCompression" in THINK C. The
   solution is to put the call, and the prototype in the header file,
   into all capitals: OPENSTDCOMPRESSION.

A better solution is to create a vocabulary file. This is just a file
with a list of names of the symbols defined in the .o file. You can
edit this file to change the all uppercase names to match the names in
the header files. See the User Manual, p. 275, for more info.

   The OConv utility seems to create a project that can't be opened by
   THINK C.  Does anyone know why this is? I get a "ZREF error" -
   "Please remove objects" when I try to open the resulting project
   file.

This is strange. I've converted the libraries before and haven't seen
this problem; make sure that you're using C 5.0.2. You don't need to
open up the projects anyway -- you should just use them as libraries,
as you'd use the MacTraps project.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

---------------------------

End of C.S.M.P. Digest
**********************